Surface workers blocked on a permission prompt (#31) - #54

Fixes #31.

The problem

A run blocked on a can_use_tool permission prompt sets awaitingInput (runner.js) but stays at status working — and nothing downstream told anyone:

• thread_status (the orchestrator's MCP tool) returned only status / lastAssistantText / lastError, so an orchestrator polling a quiet worker saw "working" and nothing else.
• The wake path (queueOrchNotice) fires only on done / failed.
• shouldNotify only fired on working -> done / working -> failed, so no desktop notification either.

Net effect: an unattended worker sits blocked forever and the stall is invisible.

What changed

electron/orchServer.js — thread_status now returns awaitingInput, plus awaitingPermission: what the run is actually asking for, read from the runner's existing getPendingPermission (already used by ipc.js, so no new plumbing). awaitingInput is guarded on status === "working" — the same guard Sidebar.tsx:223 uses — so a stale flag left behind by a run that died mid-prompt does not read as blocked. The tool description and the server INSTRUCTIONS now tell an orchestrator to check it when a worker goes quiet.

electron/notify.js + electron/main.js — shouldNotify gained a synthetic "waiting" state (working + awaitingInput), derived in main.js by a small threadNotifyState() helper used both for the live push and the boot seed. A run that blocks while the window is in the background posts a "needs permission" notification; the later waiting -> done/failed still notifies, and waiting -> waiting does not re-fire on every push.

What I deliberately did not do

Wake the orchestrator on waiting. It cannot answer a permission prompt, so a notice would just make it spin — notifying the human is the actual unblock. The orchestrator can see the state via thread_status when it wants it.

Verification

• node --test electron/test/notify.test.js → 6/6 pass (new cases: working -> waiting, no re-fire on waiting -> waiting, waiting -> done/failed still notifies).

• orch-server tool handlers suite passes, including a new test that a blocked worker reports awaitingInput: true with the prompt summary and that a stale flag on a failed thread reports false.

• npm run typecheck clean.

• Full npm run test:electron has 25 failing suites in this environment (real-CLI / network dependent). The failure set is byte-identical before and after this change — diff of the two not ok lists produced no output.

• PR created by the Claude Code agent